Migrate to VM v0.22 and protocol v0.14 by greenhat · Pull Request #995 · 0xMiden/compiler

greenhat · 2026-03-04T11:36:36Z

This PR migrates the compiler and SDK stack to the newer Miden VM/runtime APIs, centered around miden-vm 0.22 and the corresponding protocol/base updates.

On the compiler side, this updates wasm lowering/codegen to match the new VM conventions, including the generalized sign-extension op, corrected little-endian limb handling for 64-bit values, and removal of legacy intrinsics in favor of the newer core/stdlib entry points.

The Miden SDK public API changes in this PR are:

Asset changes from a single-word layout (inner: Word) to a two-word layout (key: Word, value: Word), and Asset::new now takes (key, value).
asset::build_fungible_asset / asset::build_non_fungible_asset are renamed to asset::create_fungible_asset / asset::create_non_fungible_asset.
active_note::get_inputs() is renamed to active_note::get_storage().
input_note::get_inputs_info() is renamed to input_note::get_storage_info(), and InputNoteInputsInfo becomes InputNoteStorageInfo { commitment, num_storage_items }.
active_account gains get_asset and get_initial_asset for direct vault lookups by asset key.
AccountId, Tag, NoteIdx, and NoteType now convert to/from Word, and StorageSlotId adds to_suffix_prefix().
The top-level SDK re-export Felt and Word from miden_field(miden-core).

Triggered by the migration changes in this PR:

Generalize wasm sign-extension lowering/codegen and add explicit coverage for the new i32/i64 sign-extension cases.
Fix 64-bit limb ordering in MASM memory/int codegen and related evaluation/codegen tests.
Add the missing cabi_realloc runtime export required by generated component bindings when values are passed indirectly (Triggered by the Asset becoming two word size).

This PR is quite large. I suggest reviewing it on a per-commit basis, skipping not-important commits.

TODO:

switch to the published miden-debug
switch to the published miden-client in the network tests

miden-clien migration PR - 0xMiden/miden-client#1891

greenhat · 2026-03-16T12:59:16Z

The integration tests are to be migrated after 0xMiden/miden-client#1891 is ready/merged.

greenhat · 2026-03-24T14:09:46Z

@bitwalker @mooori I'm mostly finished with this PR. I'm combing through it to do some cleanups and I'm waiting for the client/node PR updated with released protocol crates.
With these cautions, I think you can review it.

I suggest to review it on a per-commit basis, skipping non-important commits.

Migrate the compiler workspace from miden-vm v0.20 (crates.io) to v0.21.1 (local checkout) and miden-base v0.13 to v0.14. Key breaking changes addressed: - Remove FieldElement/StarkField traits (now inherent methods on Felt) - .as_int() -> .as_canonical_u64() across all crates - miden_core::Program -> miden_core::program::Program - miden_core::AdviceMap -> miden_core::advice::AdviceMap - miden_core::utils::{Serializable,Deserializable} -> miden_core::serde::* - miden_assembly::utils::Deserializable -> miden_assembly::serde::* - Felt::ELEMENT_BYTES/read_from_bytes/elements_as_bytes removed - Felt::inv() -> Field::try_inverse() - StackOutputs::get_stack_item() -> get_element() - miden_processor::AdviceInputs -> miden_processor::advice::AdviceInputs - MASM: u32overflowing_mul -> u32widening_mul - MASM: u32overflowing_madd -> u32widening_madd - Breakpoint instruction removed (mapped to Nop) - NoteInputs -> NoteStorage in miden-protocol v0.14 - Felt::from(bool) removed - SmtLeaf::to_elements() now returns iterator (needs .collect())

build

use re-exported trait from the `miden-field`.

greenhat · 2026-03-25T15:21:51Z

@bitwalker @mooori I finished the new VM v0.22 migration and switched to the released crates. It's ready to be merged.

EDIT: The only git deps left are miden-debug (pointing to 0xMiden/miden-debug#42) and miden-client (used only in the network tests suite).

huitseeker · 2026-03-25T16:03:11Z

frontend/wasm/src/component/lift_exports.rs

            diagnostics.diagnostic(Severity::Error).with_message(message).into_report()
        })?;

+    if cross_ctx_export_sig_flat.params().iter().any(|param| param.ty.is_pointer()) {


This turns a previously supported #[component] export shape into a hard failure IIUC?

I believe this is handling the case where specific heap-allocated types that are valid in the Canonical ABI (such as list<T>), but which we do not yet support, are being passed across the component boundary. In the Wasm Component Model, it is left to the Wasm runtime to copy those types from the memory of the caller component to the memory of the callee component - and for our purposes we must emit code which uses the advice provider for that. IIUC, this is just raising a diagnostic to notify the user that support for such types are not yet implemented.

I do think the diagnostic message is misleading though (unless I'm mistaken about why this check is being performed here - but we can't ever allow arbitrary references to caller memory to be passed across a component boundary, with the exception I noted above). It might be better to elaborate on what specifically the issue is (i.e. is it a matter of using something like list<T> when we haven't implemented support for that Canonical ABI type yet - or is it an attempt to pass a pointer across the component boundary, which we will never support)

I changed the error message in da45c32.
Yes, this is about passing the call parameters through the advice provider which we are not yet supporting.

huitseeker · 2026-03-25T16:10:26Z

frontend/wasm/src/component/flat.rs

        }
        Type::F64 => return Err(CanonicalTypeError::Reserved(ty.clone())),
        Type::Felt => vec![AbiParam::new(Type::Felt)],
+        Type::Enum(enum_ty) => flatten_type(context, enum_ty.discriminant())?,


Do flattening and wrapper generation now disagree on enums?

It looks like any import/export that contains an enum inside a transformed struct/result will get through flattening and then fail during wrapper generation. Should we either teach load/store to handle enums the same way, or keep rejecting enums here until that path exists?

Agreed, this flattens the enum type to its discriminant type here (so we should at least have assert!(enum_ty.is_c_like()) to catch the as-yet-unimplemented full breadth of the enum type in the Canonical ABI) - but then the load and store implementations in canon_abi_utils return an error, rather than matching the behavior here (i.e. by assuming that the enum is C-like, and thus that we're loading/storing the corresponding discriminant type).

Good catch! Done in b45ba94. We have #111 where I plan to implement the enum support in full.

bitwalker · 2026-03-25T20:26:01Z

FYI miden-debug v0.6.0 has been published with the v0.22 upgrade

bitwalker · 2026-03-25T20:41:40Z

codegen/masm/src/emit/unary.rs

+            // Zero-extending a u64 to u128/i128 requires adding an extra 0u64 *above* the
+            // existing u64 in significance, i.e. below it on the operand stack (LE limb order).


Suggested change

// Zero-extending a u64 to u128/i128 requires adding an extra 0u64 *above* the

// existing u64 in significance, i.e. below it on the operand stack (LE limb order).

// Zero-extending a u64 to u128/i128 requires us to provide the most-significant bits of the

// resulting 128-bit value. This is acheived by pushing a `0u64` value _below_ the current u64

// value on the operand stack, as the limb order of multi-limb integer values is little-endian

NIt: I find the wording of this awkward, this is how I'd phrase it instead

Done in 9cf1a27

bitwalker · 2026-03-25T20:43:29Z

codegen/masm/src/lower/lowering.rs

 impl HirLowering for hir::Breakpoint {
    fn emit(&self, emitter: &mut BlockEmitter<'_>) -> Result<(), Report> {
-        emitter.emit_op(masm::Op::Inst(Span::new(self.span(), masm::Instruction::Breakpoint)));
+        emitter.emit_op(masm::Op::Inst(Span::new(self.span(), masm::Instruction::Nop)));


Let's remove this operation entirely from the hir dialect

Done in c0909b7

bitwalker

I spent most of this afternoon going through this, and it looks good! I did have a few nits/tweaks that I'd like to make before merging, but just ping me for another pass once those are settled and we can get this merged.

bitwalker · 2026-03-25T20:56:25Z

frontend/wasm/src/component/flat.rs

+/// Identifies whether canonical ABI flattening is being performed for an exported component
+/// function or for a lowered import wrapper.
+#[derive(Debug, Copy, Clone, PartialEq, Eq)]
+pub enum CanonicalAbiMode {


I would clarify that what's actually happening here, IMO the terminology should work like this:

Lift - means we are "lifting" a core Wasm function into the Canonical ABI (i.e. we're synthesizing a CallConv::ComponentModel function that will be exported, which internally calls the underlying function). The implementation of that function is "lowering" (flattening) arguments into the underlying ABI, and "lifting" results into the Canonical ABI.

Lower - means we are "lowering" a Canonical ABI function into the underlying ABI (i.e. we're synthesizing a CallConv::Wasm function to call the Canonical ABI function). The implementation of that function is "lifting" arguments into the Canonical ABI, and "lowering" (flattening) results into the underlying ABI.

Better yet, it might make more sense to just change the names here to Export and Import to make it clearer what semantic action is being performed, and just document the WAT syntax it maps to (i.e. (canon lift) or (canon lower)).

Regardless, the terminology and semantics of this is very subtle, and I'd like to make it crystal clear what they map to.

Thank you! Done in 721e896

bitwalker · 2026-03-25T21:02:38Z

frontend/wasm/src/component/flat.rs

        }
        Type::F64 => return Err(CanonicalTypeError::Reserved(ty.clone())),
        Type::Felt => vec![AbiParam::new(Type::Felt)],
+        Type::Enum(enum_ty) => flatten_type(context, enum_ty.discriminant())?,


Agreed, this flattens the enum type to its discriminant type here (so we should at least have assert!(enum_ty.is_c_like()) to catch the as-yet-unimplemented full breadth of the enum type in the Canonical ABI) - but then the load and store implementations in canon_abi_utils return an error, rather than matching the behavior here (i.e. by assuming that the enum is C-like, and thus that we're loading/storing the corresponding discriminant type).

bitwalker · 2026-03-25T21:15:39Z

frontend/wasm/src/component/lift_exports.rs

            diagnostics.diagnostic(Severity::Error).with_message(message).into_report()
        })?;

+    if cross_ctx_export_sig_flat.params().iter().any(|param| param.ty.is_pointer()) {


I believe this is handling the case where specific heap-allocated types that are valid in the Canonical ABI (such as list<T>), but which we do not yet support, are being passed across the component boundary. In the Wasm Component Model, it is left to the Wasm runtime to copy those types from the memory of the caller component to the memory of the callee component - and for our purposes we must emit code which uses the advice provider for that. IIUC, this is just raising a diagnostic to notify the user that support for such types are not yet implemented.

I do think the diagnostic message is misleading though (unless I'm mistaken about why this check is being performed here - but we can't ever allow arbitrary references to caller memory to be passed across a component boundary, with the exception I noted above). It might be better to elaborate on what specifically the issue is (i.e. is it a matter of using something like list<T> when we haven't implemented support for that Canonical ABI type yet - or is it an attempt to pass a pointer across the component boundary, which we will never support)

frontend/wasm/src/component/lift_exports.rs

bitwalker · 2026-03-25T21:26:12Z

frontend/wasm/src/translation_utils.rs

        Type::U64 => builder.u64(0, SourceSpan::default()),
        Type::F64 => builder.f64(0.0, SourceSpan::default()),
        Type::Felt => builder.felt(Felt::ZERO, SourceSpan::default()),
+        Type::Enum(enum_ty) => emit_zero(enum_ty.discriminant(), builder, diagnostics)?,


We need to make sure we assert is_c_like on these everywhere that we handle them like this (i.e. by treating the enum as its discriminant type), so that we can catch any misses later when we flesh out enum support for the Canonical ABI

Done in b45ba94

Cargo.toml

parameters via the advice provider in a cross-context `call`

greenhat · 2026-03-26T08:07:11Z

Thank you! I addressed the review notes. Please do another round.

greenhat force-pushed the pr/migrate-to-v0.21.1 branch from d59d8d4 to 3a01c88 Compare March 10, 2026 05:59

This was referenced Mar 17, 2026

feat: rework test-harness for integration tests #896

Closed

Use MASM attribute to mark authentication procedure in the authentication component (instead of "auth_" prefix) #982

Open

greenhat force-pushed the pr/migrate-to-v0.21.1 branch from dcf2c50 to 99777a4 Compare March 20, 2026 07:35

greenhat mentioned this pull request Mar 20, 2026

OutputNoteError::NoteSizeLimitExceeded error with the Rust P2ID note script 0xMiden/protocol#2648

Closed

djolertrk mentioned this pull request Mar 23, 2026

Track variable locations #820

Open

greenhat force-pushed the pr/migrate-to-v0.21.1 branch 2 times, most recently from 12bd9e8 to bb280a8 Compare March 24, 2026 13:52

greenhat requested review from bitwalker and mooori March 24, 2026 14:25

greenhat changed the title ~~Migrate to VM v0.21 and protocol v0.14~~ Migrate to VM v0.22 and protocol v0.14 Mar 25, 2026

greenhat force-pushed the pr/migrate-to-v0.21.1 branch from 0183581 to 9999250 Compare March 25, 2026 13:06

djolertrk and others added 12 commits March 25, 2026 15:13

fix: rename rpo256 module to poseidon2

42c4aff

chore: switch to git branches for the protocol crates and debug, fix

12af6d2

build

refactor: switch to the miden-field from miden-crypto

704cbc5

refactor: remove Word type and use miden_field::Word instead

c11b7cd

refactor: simplified StorageMapAccess for StorageMap

e3d31f2

refactor: change the shape of the Word type from tuple to named fields

3794f85

fix: after rebase, remove p3-field dependency and

29f6a25

use re-exported trait from the `miden-field`.

fix: miden-field-repr build for the release checks CI job

b6d4bf0

chore: update git commit for miden-field

11a18b6

fix: dependencies in test projects, stdlib rpo256 rename

bc8156a

refactor: remove i128 MASM intrinsics and use miden::core::math::i128

8d104cf

greenhat force-pushed the pr/migrate-to-v0.21.1 branch from 9999250 to 95ef09a Compare March 25, 2026 13:17

greenhat added 4 commits March 25, 2026 16:27

chore: migrate to VM v0.22 and use published v0.14 protocol crates

cbb4ad2

fix: objtool after rebase (migrate to VM v0.22)

5339177

test: enable the network tests after the miden-client bump

db89a35

chore: bump auth proc cycle count

d621f0a

greenhat force-pushed the pr/migrate-to-v0.21.1 branch from eb7e4a9 to d621f0a Compare March 25, 2026 14:27

chore: panic on unhandled miden stubs on Wasm transformation

13d4402

greenhat mentioned this pull request Mar 25, 2026

fix: unaligned memcpy #1004

Merged

greenhat marked this pull request as ready for review March 25, 2026 15:41

huitseeker reviewed Mar 25, 2026

View reviewed changes

bitwalker reviewed Mar 25, 2026

View reviewed changes

bitwalker requested changes Mar 25, 2026

View reviewed changes

greenhat added 7 commits March 26, 2026 08:02

chore: switch to miden-debug v0.6 (targeting VM v0.22)

3310e5b

chore: re-word the error message for unsupported (yet) passing the

da45c32

parameters via the advice provider in a cross-context `call`

fix: restrict canonical ABI enum handling to C-like enums

b45ba94

refactor: remove the HIR breakpoint operation

c0909b7

refactor: clarify canonical ABI wrapper modes

721e896

docs: clarify u64 zero-extension limb ordering

9cf1a27

test: match the updated export lifting diagnostic

c8b93fc

greenhat requested review from bitwalker and huitseeker March 26, 2026 08:07

greenhat mentioned this pull request Mar 26, 2026

refactor(sdk): derive storage slot names from package and struct #1035

Merged

bitwalker approved these changes Mar 26, 2026

View reviewed changes

bitwalker merged commit b4b5af7 into next Mar 26, 2026
15 checks passed

bitwalker deleted the pr/migrate-to-v0.21.1 branch March 26, 2026 16:59

greenhat mentioned this pull request Mar 27, 2026

Tracking issue for unified Felt type #880

Closed

		// Zero-extending a u64 to u128/i128 requires adding an extra 0u64 above the
		// existing u64 in significance, i.e. below it on the operand stack (LE limb order).

-            // Zero-extending a u64 to u128/i128 requires adding an extra 0u64 *above* the
-            // existing u64 in significance, i.e. below it on the operand stack (LE limb order).
+            // Zero-extending a u64 to u128/i128 requires us to provide the most-significant bits of the
+            // resulting 128-bit value. This is acheived by pushing a `0u64` value _below_ the current u64
+            // value on the operand stack, as the limb order of multi-limb integer values is little-endian

Conversation

greenhat commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

greenhat commented Mar 16, 2026

Uh oh!

greenhat commented Mar 24, 2026

Uh oh!

greenhat commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bitwalker commented Mar 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bitwalker left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

greenhat commented Mar 26, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

greenhat commented Mar 4, 2026 •

edited

Loading

greenhat commented Mar 25, 2026 •

edited

Loading